前言

在前幾天的介紹中，我們介紹了 RFC9000 中描述的一些基本名詞概念，今天終於要開始攻略第一個 QUIC 的重要關卡 - Handshake 流程。

Handshake 是一個比較大的主題，可能會分成多天去介紹(因為筆者沒有屯稿，所以也不知道具體會寫幾天)，Handshake 流程的改進也算是 QUIC 發展的緣由之一，請看下方的經典 network stack 圖

在現代網路服務追求低延遲的背景下，過往 TCP + TLS 的組合面臨嚴重的挑戰 - 過於冗長的建立連線過程導致用戶在網路情況不佳的情況下會感受到延遲。

在現在網路基本上默認 HTTPS 的環境下，底層 TCP + TLS 協定是必須的，在今天的介紹中我們就先來介紹 TCP + TLS1.3 建立連線所需的時間，後續再來講解 QUIC 是怎麼透過嵌入 TLS 來降低建立連線的延遲。

TCP + TLS1.3 建立連線分析

分析建立連線的速度要先做一點假設，Client 是否曾經訪問過這個網站/Server，通常你要優化效率第一個想到的一定是在某些東西做 cache，不管是 TLS 協定或者 QUIC 實現的 0-RTT 都是在某些環節做 cache 達到的，等等會分別簡述有沒有曾經訪問過該網站的連線建立流程。

當輸入網址進瀏覽器之後，大致上可以分成四個步驟

DNS

透過 DNS 獲得 IP，因為查詢結果可能會因為有沒有 cache 導致時間落差很大，本文在估算 RTT 的時候就沒辦法精準的估算 DNS 查詢的時間。

TCP 握手

在開始 TLS 連線之前會先進行經典的 TCP handshake，因為 Client 在收到 SYN-ACK 後就可以開始送資料了，所以 TCP 連線會耗費一個 RTT 的時間。

TLS

QUIC 中的 TLS 協定強制使用 TLS 1.3 版本，但一般使用上也要看自己的瀏覽器支援的版本，TLS 1.2 與 TLS 1.3 最大的差別是 TLS 1.3 為 handshake 流程做了一定的優化，並改善了很多加密演算法的安全性。

以 TLS 1.2 來說，需要 2RTT 來建立連線，如果不是首次連線，連線雙方也有支援的話可以開啟 Session Resumption 功能，把第二次及以後的連線建立時間縮短為 1RTT。

接著來說一下 TLS 1.3，TLS 1.3 一般建立連線時間縮短為 1RTT，並且增加 0-RTT 模式，但這邊的 0-RTT 模式是以 TLS 協定的角度，在 TLS 協定協商密鑰時就能附帶部份 data 傳送。以使用者的角度整個流程還是需要 1RTT 以上，因為這邊的 0-RTT 模式並沒有把上面 TCP 協定 handshake 花費的 1RTT 算入其中。

關於 TLS 的 handshake 流程本文就不再多贅述，如果想進一步了解可以參考以下文章

• HTTPS 溫故知新（三） —— 直觀感受 TLS 握手流程(上)
• HTTPS 溫故知新（四） —— 直觀感受 TLS 握手流程(下)

HTTPS

最後則是應用層走 HTTPS，假設這次 Request 要的資料只要一次請求即可獲得，那麼 HTTPS 也需要花費 1RTT 的時間。

簡單統計一下，如果採用的是 TLS1.2

• 首次連線的時間成本: TCP(1RTT) + TLS(2RTT) + HTTPS(1RTT) + DNS
  • 4RTT + DNS
• 開啟 TLS1.2 Session Resumption 成本: TCP(1RTT) + TLS(1RTT) + HTTPS(1RTT) + DNS
  • 3RTT + DNS

乍看之下在目前網路速度越來越快的大環境下，好像 3~4 個 RTT 就能完成一次 request 好像已經很理想了，但仔細想想如果今天我們想跟 Server 要的資料只需要一次 HTTP 的 request 就可以完成，那代表整個請求的時間中，真正跟 Server 要資料的時間只有不到一半，剩下的時間大部份都花在建立連線的繁瑣流程中。

下圖是 TCP + TLS 在不同情況下建立連線的流程圖，

來源

可以在上圖中觀察到 TLS 本身一直在努力的想要降低建立連線的時間，但不管再怎麼努力都卡在分層的瓶頸上，在 TLS 開始建立連線之前一定要花費建立 TCP 連線的一個 RTT。

之前背景介紹時有簡單提到，因為 TCP 本身已經沒辦法做太大的變更，在基於 TCP 的前提下，無論後續建立連線有多快，甚至 TLS 1.3 已經達到了 0-RTT 的程度，也會因為分層的概念讓建立連線保底就是一個RTT。

明天的文章我們會正式開始介紹 QUIC 的 Handshake 流程，透過把 TLS 本身嵌入 QUIC 中，讓分層的概念消失，達到真正的 0-RTT。